The development of virtualization technologies has made it possible to execute multiple virtual machines (VMs, also called “guests”) on a single host machine. Virtualization software may execute on a host machine to support the execution of the VMs. As described briefly below and in numerous earlier patents and patent applications, including patents and applications assigned to VMware, Inc., such a virtualization system may take various forms, including either a hosted system or an unhosted or kernel-based system. Running multiple VMs on a single host can significantly improve the utilization of the underlying hardware resources on the host. Many resource management mechanisms provided by the operating system (OS) in a conventional host machine are also available at the VM level.
In a computer system, the OS typically provides a virtual memory space that is greater than the available physical memory space. In a virtualized environment, an OS executing within a VM may provide a virtual memory space that is greater than the “physical” memory space of the VM. Also, virtualization software may use a technique called memory over-commitment to give the appearance that the total memory included in all the VMs exceeds the actual memory in the host hardware. Thus, more apparent memory can be present at both the guest level and host level. For example, a host machine may have 4 GB of physical memory in its hardware (referred to as “machine memory”). At the guest level, a VM may be configured to have 4 GB of virtualized “physical” memory (referred to as “guest physical memory”) and provide 8 GB of virtual memory space (referred to as “guest virtual memory”) to the guest processes. Furthermore, the host may accommodate multiple such VMs.
As described in earlier patents and applications, a hosted virtual computer system may comprise virtualization software executing on a host hardware platform, along with a separate host OS, while an unhosted virtual computer system does not include a separate host OS. As is well known, in an unhosted virtual computer system, the virtualization software performs some of the functions performed by the host OS in a hosted virtual computer system. Thus, in an unhosted virtual computer system, the virtualization software may be thought of as including a subset of the OS functionality included in the host OS of a hosted virtual computer system. In this patent, the OS functionality in the virtualization software of an unhosted virtual computer system may be referred to as a host OS, even though the virtual computer system does not include a separate OS, distinct from the virtualization software, at the host level. The virtualization software may comprise or be referred to as a virtual machine monitor (VMM) or a hypervisor. Also in this patent, the term “host” may be used to refer to virtualization software executing on a host physical hardware platform and supporting the execution of one or more VMs. In a hosted virtual computer system, the term “host” also includes a separate host OS. Also in this patent, the term “host MMU” (memory management unit) may be used to refer to software that performs memory management functions at the host level of a virtual computer system, whether the system is a hosted system or an unhosted system.
In general, an OS (either at the host level or guest level) may attempt to map as much virtual memory space as possible to the physical memory space. When another page of physical memory is needed, but there are no physical memory pages available, the OS performs a process called “swapping,” during which the OS copies, or “swaps out,” one or more pages from physical memory to a secondary storage (e.g., a hard disk) in order to free up physical memory and to meet memory allocation requests by applications. Such swapping can occur at both the host level and guest level.
During swapping at the host level, the host MMU frees up machine memory by copying one or more pages from the machine memory to one or more swap files stored on a hard disk. Similarly, during swapping at the guest level, the guest OS copies one or more pages from the guest physical memory to the guest's persistent storage (e.g., a virtualized hard disk, which can be a file on the host's hard disk). Note that host-level swapping and guest-level swapping may occur separately and are typically independent from each other.
One way to achieve better coordination between host-level swapping and guest-level swapping is to use a process called “ballooning.” A “balloon driver” (also called “balloon”) is resource reservation code that runs as a driver in the VM and that requests guest memory (which will be allocated by the guest OS but not used meaningfully by any process on the guest). A balloon application could also be used instead of, or in addition to, a balloon driver. In response, the guest OS allocates some guest memory to the balloon driver. Meanwhile, since the balloon driver has now reserved more guest memory, the guest OS's memory management unit may swap out previously allocated guest physical memory pages to the persistent storage in order to satisfy the requests by the balloon driver. The balloon driver identifies the corresponding guest physical memory and notifies the virtualization software on the host about the identified guest physical memory. Subsequently, the host MMU may map one or more pages of the identified guest physical memory to a shared page in the machine memory (since the corresponding guest memory pages are not used meaningfully by any guest process), and frees up machine physical memory pages which can be used by other VMs.
For example, assume that a host has 4 GB of machine memory, and is hosting two VMs (VM 1 and VM 2). Each VM is configured with 4 GB of (virtualized) guest physical memory. Assume further that VM 1 is now using close to 4 GB of the host's machine memory. The host's memory management unit can instruct a balloon driver on VM 1 to request 1 GB of guest memory. As a result, the guest OS on VM 1 allocates 1 GB of guest physical memory to the balloon driver, and in doing so swaps out about 1 GB from its guest physical memory to make this space available. Note that the balloon driver can regularly keep accessing this 1 GB of virtual memory so that it remains mapped into the guest physical memory, but does not use this 1 GB of virtual memory in any meaningful way. Alternatively, the balloon driver may pin the memory pages in guest physical memory. The balloon driver communicates information about this 1 GB of memory to the memory management unit on the host. The host MMU can then map this 1 GB of guest physical memory to one single shared page in the machine memory, which can have a size of 4 KB. Hence, in effect, the 1 GB guest memory allocated to the balloon driver on VM 1 is now mapped to only 4 KB of machine memory. Since the guest OS swapped out 1 GB of guest physical memory to make space for the balloon request and the actual machine memory used by the balloon is about 4 KB, about 1 GB of machine memory is now freed and can be used by VM 2. Hence, the ballooning process effectively forces the guest OS to perform swapping at the guest level to reclaim machine memory. More details about using ballooning to manage VM virtual memory can be found in U.S. Pat. No. 8,359,451, which is incorporated herein by reference in its entirety.
Both host-level swapping and guest-level ballooning allow less frequently accessed memory pages to be temporarily stored on hard disk, so that more machine memory can be available for other applications (e.g., other VMs). However, when an application needs to access a swapped-out page, the OS must swap-in this page from hard disk to the memory. This is a time-consuming process and can incur significant performance overhead. For example, when a user leaves a VM running at the end of the day, the virtualization infrastructure host may swap out the host physical memory previously used by this VM and re-allocate such memory to other VMs. Then, when the user returns the next day, the guest OS might take minutes to swap in the swapped-out content into the memory before the VM is responsive again. Such delay in VM response time negatively impacts the user experience and is undesirable.